电商业务测试方案与实战落地（转转）
作者|田西西
测试方案首先要了解业务特性、测试痛点，才能定制合理的测试方案，使得方案即可以满足当前业务形态的测试，又满足对未来可期需求的支持甚至对未来系统重构做提前打算。
对于微服务架构的系统也有个比较初始的阶段，虽说不是all in one的这种架构，但也是多业务耦合在一起的，因为业务初期业务形态并未完全成型。
All in one 能尽可能快速的满足现有需求，同时又能降低当时背景下的维护成本。
初期的测试系统也是类似思想，按照当时的背景，接口测试、ui测试刚刚起步都是为了解决当前问题满足业务快速上线而设计的，一步到位或者过于激进的设计往往会拖慢进度。
初期接口调用client初始化、测试数据初始化、接口调用、结果校验都在一个Test方法中 这样能快速响应当前需求、尽快达到测试效果。
随着业务发展，交易系统和交易的测试用例都有一系列的改版升级，对于交易系统是微服务的横向拆分、纵向拆分，原有的交易系统内部有了明显的业务隔离，有一个指标特别明显，那就是出现单个服务排队上线的问题，这是从QA角度上最直观感知到服务需要拆分的指标。
经过从业务维度的拆分，也就有了左侧的交易系统，在原有系统上增加了一层带有运营属性的服务。玩法的出现和增长让原有交易系统的业务量开始暴增。
对于case原有的all in one的case不再满足快速支持业务的目标。直观的感受，case的量也随着不停的增加、冗余代码量的增加，同一接口在不同的case中反复调用，同一类校验方法在不同的case中反复编写。
基于上面业务变动导致原有模式已经无法满足现状，我们将case初步抽象、减少冗余，便有了右侧图的测试系统接口。
统一的数据提供，同一接口的调用抽象出Action Collection模块，每个接口通过参数区分调用接口要做的操作；抽象校验方法，独立出Assert模块，将类似的校验集中在一起，通过参数区分期望结果；Case层仅调用接口组合操作并在操作调用当前操作的校验方法就可以了。
这样便解决了冗余的问题，大量接口和校验方法的复用让接口测试的效率又提高了起来。
随着垂直业务的增加，又因为每个垂直业务的玩法不同，所需要的交易链路就有着不同的要求，给每个垂直业务单独开发、维护一套交易链路，对交易系统甚至交易业务来说人力成本、维护成本都是无底投入。
所以切面化的交易系统就产生了，交易维护核心交易链路，并将业务个性化内容以切面的形式托管给业务自定义处理。
根据切面化的思想我们在测试系统中通过动态代理构建出两层切面。一个在操作层，一个在请求发送的client层。
操作层的代理将校验单独独立出来，与操作分离，通过上下文进行衔接，用例不用再关心校验，只需要调用操作接口，如此更进一步降低了用例编写成本，当然校验系统的设计成本也有所提升。但是整体用例成本的降低也让RD可以在测试系统上编写测试用例，且不管什么参数流入校验系统，校验系统均能处理并计算出期望值，通过查询业务系统接口或者数据库等进行校验。
另一层代理client层，可以做一些基于请求和返回的测试工具，比如diff工具，满足重构类需求的测试。
切面状态机流转，通过配置的在某个扩展点锁住当前状态，执行扩展操作，将订单渲染托管给第三方，直到当前状态解锁。
随着业务发展与系统重构交易系统横向划分也越来越清晰，上层为业务系统、促销系统，中层为交易系统、支付中心，底层为清结算中心。
业务横向划分对交易系统来说业务结构更加清晰，系统维护更加便利，但是对测试来说是一个挑战。上层业务小小的改动，或者底层业务小小的改动都会带来大量的回归工作。
基于问题，测试系统改进为可扩展化的测试系统，改进方案是在校验系统的上层抽象出一层计算系统，计算系统维护所有的状态流转数据、计算公式等，整体结构与上一版本并没有大的变化，主要是计算和校验剥离的更加清晰，计算更加可维护可扩展。如此上层业务的改动仅需要在抽离的公式中维护对应的变量就可以做到全业务回归。
操作执行后封装上下文，通过代理触发校验，校验发现本次操作影响到了其他上下文，如订单操作影响到红包、商品，需要再维护红包商品的上下文，上下文更新后再触发对应红包、商品的校验。
经过多次升级，上图是最终测试系统的架构，两层代理和独立的上下文维护模块，独立的校验模块。
比如各类单据流转系统，都可以参考用例、操作、上下文、校验系统的测试方案，交易系统中的订单系统其实就是状态机系统的一个应用。
切面系统的测试点是切面能力。因为构建切面是为了将更多的自定义能力托管给业务，那么对于中台来说，更多的测试工作是对切面能力的保证。
因为切面的构造基于配置，所以对应的测试系统要验证配置能力、托管接口能力，测试方法如右图。
数据构造模块插入各种配置，用例执行命中配置的操作，执行托管接口，校验配置的生效性和托管接口的生效性。
策略类和切面类的相似之处是基于配置，策略类业务场景包括风控、支付风控等业务场景。
配置策略，触发操作，测试策略引擎，验证配置。测试策略引擎是轻量的描述策略的集合。
异常分为服务内部异常，领域内部异常（服务间异常），与三方服务的异常。
服务间异常可以通过RPCmock、httpmock ，服务内部异常可通过插桩方案注入异常。
往期精彩回顾